Jira link

See PO-3412,
PO-2948

Change description

Problem

PO-3412

Entering an offence code that is valid itself but also has related sub-codes could show an incorrect “Offence not found” message in Manual Account Creation.

Example:

• User enters CD71039
• API returns CD71039, CD71039A, CD71039B, CD71039C
• UI shows “Offence not found” even though CD71039 is present in the response and the intended code to display

This created an inconsistent journey because the review screen could still appear to show the correct offence later in the flow.

PO-2948

Entering an invalid offence code that fits basic validation by being 7 or 8 characters long, e.g. "TESTTEST", and immediately submitting the code before the application has had the chance to receive the backend response will allow the user to continue with an invalid code.

Cause

PO-3412

The cause of this was the conditional logic on fines-mac-offence-code-hint.component.html set to display the retrieved offence code only when response.count === 1. This means when a code not only pulls itself down from the backend but also all sub-codes the response count is more than 1 and this condition defaults the page to show "No offence found".

In general multiple codes being returned in the response hasn't been accounted and these issues affected a few places:

That affected a few places:

• The shared offence-code listener only populated offence_id when response.count === 1
• The hint panel showed “Offence found” only when count === 1
• Some review components relied on refData[0], which only worked if the exact match happened to be the first returned item

So for multi-result responses containing a valid exact match, we could:

• show the wrong validation state
• leave offence_id unset
• display the correct offence later only by coincidence, depending on response ordering

PO-2948

When a user entered a lookup-length offence code, the form kicked off async backend validation, but there was a window before the response came back where the form could still be submitted. If the user submitted during that gap, the offence code had not yet been marked invalid and the unresolved lookup had not blocked submission, so an invalid code could slip through.

Solution

PO-3412

The primary fix here is to change the condition that determines between displaying the offence code or error. Instead of checking for the number of responses, we should be looking for an exact match from all codes in a given response.

Fixes:

• find the returned offence whose code exactly matches the entered code
• treat that as the valid offence, even if other related codes are also returned
• populate offence_id from that exact match
• use the same exact-match logic in the hint and review displays

This keeps the behaviour consistent across:

• offence entry
• offence hint panel
• offence review heading
• fixed penalty review offence display

PO-2948

When the offence code changes, the form now marks lookup-length values as validation-pending straight away and
clears the offence ID until a matching backend result resolves. On submit, the form explicitly checks whether
offence-code validation is still unresolved or whether the last lookup failed, retries failed lookups, and keeps the form invalid until the lookup either resolves to a valid offence or returns a definite invalid result.

Considerations

• This is intentionally stricter than “any results returned”: if the API returns related codes but not the exact entered code, we still show the offence as not found.
• The review screens now no longer depend on response ordering.
• The exact-match helper was kept inside the shared offence-details service
• Targeted tests were added for the multi-result exact-match scenario and the focused spec run passed.

Testing done

Manual testing

Both reported cases have been manually tested after the described changes have been implemented and confirmed to be addressed.

Unit testing

The testing approach focused on the exact-match behaviour across the full offence-code journey: service tests were used to verify that when the API returns multiple related offences, the lookup only succeeds if one record exactly matches the user-entered code, including both the positive case (CD71039 returned alongside CD71039A/B/C) and the negative case where similar results are returned but no exact match exists; targeted component tests then confirmed that the same rule is reflected in the UI, so the offence hint panel and both review displays now show the correct offence title and “Offence found” state for exact matches, and continue to show “Offence not found” where no exact match is present, removing any dependency on response ordering.

The testing for preventing early offence code submission is implemented by unit tests in the shared offence-code listener service and in both affected form components. At a high level, the tests verify that lookup-length offence codes are marked as pending immediately, submission is blocked while validation is unresolved, failed lookups are retried on submit, stale async responses are ignored when users type quickly, and the pending state is cleared once a valid offence is resolved.

Security Vulnerability Assessment

CVE Suppression: Are there any CVEs present in the codebase (either newly introduced or pre-existing) that are being intentionally suppressed or ignored by this commit?

• Yes
• No

Checklist

• commit messages are meaningful and follow good commit message guidelines
• README and other documentation has been updated / added (if needed)
• tests have been updated / new tests has been added (if needed)
• Does this PR introduce a breaking change